Hi Scott,
The Embedded Motion Wait is probably not something you need. It is designed to embed a real-time wait of something that may be very short in time (ie 1 millisecond) within a
motion sequence and to guarantee the motion continue within 90us of when the I/O changes. To do that the GCode Interpreter must have Trajectory Planned ahead (seconds) so that any Windows stalls would not cause problems. The GCode Interpreter and the Trajectory Planner always work far ahead in time from where the Machine Tool actually is. So I think you would find that the wait occurs at the right place in the motion sequence even though the KMotionCNC Screen shows a GCode line further along. After Version 4.32 the Test Versions have a mechanism to maintain a Real-Time State that more closely matches the actual Machine Tool Position. That is now used to display status (GCode Line Number, Offsets used, etc) so what is displayed is more indicative of the current machine state.
However in your case it doesn't sound like timing is super critical. If you define an M Code as a C Program that waits for a bit, things will be more logical. The M Code will then cause the Trajectory Planner to plan a complete stop, flush all buffered motion, wait for all motion to complete, download/execute the C Program, wait for the C program to finish, then refill the motion buffer, and begin executing more motion. All this will will normally happen in a few milliseconds but on very rare occasions it may be a second or so before
motion continues in the event Windows is stalled doing something critical just when it is time for the motion to continue. A Program to wait for a bit to be High before terminating could be:
#include "KMotionDef.h"
void main()
{
while (!ReadBit(46)) ;
}
The Exec/Wait Action should be selected in order for the C Program to be executed and for the Interpreter to wait for the C Program to terminate before continuing. If you have an Init program that executes in Thread #1 then choose an unused thread for this MCode so it can run in parallel (ie Thred #2).
The "Execute PC" Action Executes a Program on the PC of your choosing. It might be some .exe or .bat file.
The "PC App Callback" is an advanced feature. It provides a hook to call custom code that you add to the Host Application yourself. One user
used it somehow to call an IronPython script.
HTH
Regards
TK
From: "cnc_machines@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Sunday, November 2, 2014 9:06 PM
Subject: Re: [DynoMotion] M-Code Hold Bit
Tom,
I am using KMotion 432. I have a sensors on a work holding clamps on my CNC machine which change position as the cutter moves around the work piece. When the clamps switch positions they send a confirmation bit that they have reached full hydraulic pressure. This way I know it is okay to continue cutting.
I would like to use the M-Codes to trigger clamps closing, and M-Codes to stop the program to confirm that the action took place. Do you have any ideas on how this would function?
I am also intrigued with the options on the drop down menu "Execute PC" and "PC App Callback". Could you help me understand what these were originally designed to do?
Thanks,
Scott
